A voice over Internet Protocol (VoIP) connection is a real-time application that is sensitive to delay and jitter. To ensure high mean opinion score (MOS) of every VoIP connection, third-generation (3G) and fourth-generation (4G) telecommunications standards currently suggest allocating a fixed delay budget (e.g., preferably in the range of 50-100 ms, but not more than 200 ms) to any incoming VoIP packet that arrives at a radio access network (RAN) of a receiver. High-Speed Downlink Packet Access (HSPDA), High Speed Packet Access (HSPA) and Long Term Evolution (LTE) are examples of technology standards and/or protocols upon which such 3G/4G telecommunication network systems are implemented. To meet this fixed delay budget objective, the end-to-end path between the end-users is divided into segments that contain the RAN (radio access network) of the sender, the core IP network and the receiver RAN. For each one of these three segments, a fixed budget delay is allocated that provides an upper bound on the delay of a voice packet in each segment. Typically, the delay budgets of the RANs is between about 50 to 80 ms and about 50 ms for the core network.
Because VoIP packets can have different delay until they arrive at the receiver RAN, an alternate approach to allocating a fixed delay budget includes allocating a delay budget to each VoIP packet that is inversely proportional to the delay that the packet has already experienced in its path. A problem with this approach is that the packet delay from its originating node to the receiver RAN is unknown. One possible solution for overcoming this problem is to deploy a monitoring system that will monitor the end-to-end delay and jitter between the VoIP source node (or a node close to the source node) and the receiver RAN (e.g., a P-gateway at Long Term Evolution (LTE) networks). However, such a solution can be difficult to implement because source and the destination RANs are often managed and/or owned by different network provider entities.
In IP based 3G and 4G cellular systems, voice information is encapsulated into voice over IP (VoIP) packets and each packet is sent as an independent IP packet. In such network systems, the delay of a packet is variable and is composed of fixed and dynamic delay components. The fixed delay component results from physical constraints such as voice decoding/encoding and the propagation delay on the air and the wires. This fixed delay component is typically very small and even in the case of long distance calls (e.g., from end-to-end in USA) it is typical no more than about 30 to 40 ms. The dynamic delay component results from retransmissions (e.g., via the usage of Hybrid automatic repeat request (HARQ) mechanism) and buffering delay. This dynamic delay component is typically much more substantial than the fixed delay component.
In current implementations of delay budget allocation, a fixed delay budget is allocated to every segment along the end-to-end path to overcome the delay variability. While it is easy to implement delay budget allocation in this manner, it posses a stringent per-segment delay constraint that does not take advantages of the delay variability on a per-segment basis. Another approach for implementing delay budget allocation in a manner that takes into account the delay variability of the VoIP traffic is to allocate a dynamic delay budget to each VoIP packet at the receiver RAN based on the delay that it experienced so far. The additional delay can be used for improving the voice quality of the receiver (e.g., by allowing more HARQ retransmissions), for increasing the system capacity (e.g., by giving the RAN more flexibility to send the VoIP packets when the channel quality is good), and/or for improving voice capacity of the cells. A known problem of dynamic delay budget allocation for VoIP packets at the receiver RAN is the lack of knowledge of the packet delay before it reaches the receiver RAN. Although each VoIP packet carries a time stamp in which it was generated, this time stamp refers to an arbitrary clock at the sender side and not to a global clock. Moreover, deploying an end-to-end monitoring system in most cases in unfeasible as the sender and receiver RANs are often managed by different authorities.